Angular hat den Ruf, die beste Wahl für Enterprise-Anwendungen zu sein. Wie stehst du dazu – für welche Einsatzzwecke rätst du zur Nutzung von Angular?
Manfred Steyer: Enterprise-Anwendungen sind sicher das Hauptgebiet von Angular. Es bietet out-of-the-box so ziemlich alles, was man sich von einem Framework dafür erwartet: Dependency Injection, Formulare, Validierungen, Testing-Support, PWA-Support, Routing etc. Genau dafür wurde Angular auch bei Google entwickelt, wo es für über 1200 solcher Lösungen zum Einsatz kommt.
Das für Angular aufgebaute Know-How kann allerdings auch für andere Bereiche genutzt werden. Für Customer-Anwendungen wird zum Beispiel Server Side Rendering unterstützt. Das war dem Team sogar so wichtig, dass sie dieses Feature, das zuvor ein Community-Projekt war, mit Version 4 in das offizielle Produkt aufgenommen haben. Mit Ivy und Angular Elements wird Angular auch leichtgewichtige Komponenten und Web Components unterstützen und hier auch extrem kleine Bundles produzieren.
Thomas Hilzendegen: Dies sehe ich ganz genauso. Das Framework ist ein Allround-Talent für jegliche Einsatzzwecke. Für eine PWA, eine hybride Cordova-App oder die klassische SPA im Browser, wäre Angular meine erste Wahl. Das Ökosystem (CLI, Packages, Libraries) und die Community, sowie das verlässliche Backing durch das Team bei Google selbst ist das Fundament, auf das alle bauen können (und sollten).
Christian Liebel: Ich stimme zu: Angular ist eine hervorragende Wahl für Business-Anwendungen. Entwickler können direkt auf dem umfangreichen Lieferumfang des Frameworks starten. Auf dieser Basis können klassische Forms-over-Data-Anwendungen, 2D-/3D-Visualisierungen und/oder offline-fähige Apps entstehen, die nicht nur im Browser, sondern obendrein auch noch auf Mobil- und Desktop-Plattformen laufen. Mit Angular haben wir schon viele Anwendungsfälle aus allen erdenklichen Branchen mühelos umsetzen können.
Fabian Gosebrink: Angular bietet als Plattform viele Möglichkeiten, gerade im Bereich der Architektur auf dem Client und im Web. Ich sehe Angular in vielen Business-Applikationen im Einsatz. Angular gibt Entwicklern unter anderem mit dem Tooling wie dem CLI eine Richtlinie, wie Webapplikationen geschrieben werden sollten, andererseits aber auch genug Freiheit, die Architektur und die Trennung der Zuständigkeiten auf sich anzupassen. Darüber hinaus zeigt Angular, dass beispielsweise mit Angular Elements noch genug Potential vorhanden ist, die Plattform weiter zu entwickeln. Es ist interessant zu sehen, dass es da nicht aufhört sondern das Angular-Team versucht sich und das Produkt ständig voranzutreiben und auszubauen. Letztendlich profitieren Enterprise-Anwendungen und -Kunden ja davon.
Jede Anwendung sollte getestet werden. Welches Testing-Tool muss man für Angular unbedingt kennen (und warum)?
Manfred Steyer: Wichtig ist, dass man sich mit den Grundwerkzeugen, die das CLI out-of-the-box für Unit-Testing anbietet, auseinandersetzt. Zum Beispiel bietet Karma einige Konfigurationsmöglichkeiten zum Feinjustieren und Jasmin hat ein sehr nettes Spy-Konzept, das leider ein wenig untergeht, weil es kein direktes Angular-Feature ist. Aber auch Angular bietet zur Integration in diese Frameworks einige nette Möglichkeiten, zum Beispiel einige Hilfsmittel zum Handhaben von Asynchronität in Tests.
Wer ein wenig über den Tellerrand hinausblicken möchte, sollte sich Jest als Karma-Alternative für Unit-Tests sowie Cypress als Protractor-Alternative für E2E-Tests ansehen.
Daneben stelle ich fest, dass das Thema Test-Performance immer wichtiger wird, zumal wir immer mehr und größere Test-Suites haben. Shallow-Testing ist hier ein wichtiges Thema aber auch die Möglichkeit, nur die Tests ausführen zu können, die von den letzten Code-Änderungen betroffen sind. Die CLI-Erweiterung Nx bietet sowas zum Beispiel an.
Thomas Hilzendegen: Hier liefert das Angular CLI mit Jasmine, Karma und Protractor schon eine solide Basis, mit der wunderbar Unit- als auch End-to-End-Tests erstellt werden können. Dazu würde ich z.B. noch ‚ts-mockito‘ empfehlen, um sehr einfach Mocks zu erstellen und diese nach Belieben mit dem für den Test notwendigen Verhalten konfigurieren zu können.
Christian Liebel: Zunächst einmal müssen Entwickler natürlich die durch das CLI-Setup mitgebrachten Testing-Tools kennen: Das sind Karma/Jasmine für Unit-Tests sowie Selenium/Protractor für End-to-end-Tests. Dann gäbe es noch Jest, das im Gegensatz zu Karma ohne Browser, parallel und somit schneller testen kann – allerdings werden nicht sämtliche DOM-APIs unterstützt und bestehende Tests müssen gegebenenfalls migriert werden. Dann gäbe es noch Cypress, eine deutlich aufgebohrte, kommerzielle E2E-Testing-Lösung, die ich wegen ihres Komforts sehr schätze.
Fabian Gosebrink: Ich finde im Moment Cypress für das End-to-End-Testing sehr spannend. Es vereinfacht die doch recht komplexen Tests extrem und selbst mir hat das Schreiben von Tests auf einmal Spass gemacht 😉
Angular 9 mit Ivy kommt im Herbst. Worauf bist du besonders gespannt und welche Auswirkungen wird Ivy auf das Ökosystem haben?
Manfred Steyer: Kurzfristig werden leichtgewichtige Anwendungen und Komponenten, die viele Möglichkeiten von Angular gar nicht benötigen, am meisten profitieren. Das betrifft auch Web Components. Hier werden wir dank Ivy stark optimierte Bundles bekommen, die sich mit jenen von einfacheren Frameworks messen können oder deren Fußabdruck sogar unterbieten. Normale Anwendungen werden kurzfristig ein wenig von Ivy profitieren, da auch hier die Bundles kleiner werden dürften. Das hängt aber sehr stark vom Anwendungsfall ab.
Mittelfristig bietet Ivy in der Welt von Angular ganz neue Möglichkeiten, zum Beispiel einen Betrieb ohne NgModules. Dieses Konzept führt bei Einsteigern immer wieder zu Verwirrung, weil es auf den ersten Blick keinen Sinn macht, neben dem ECMAScript-Modul-System ein weiteres Angular-spezifisches zu haben. Auch das Angular-Team, das NgModules aus technischen Gründen einführen musste, sieht das so. Dank Ivy werden diese NgModules früher oder später optional werden.
Ivy ist mittelfristig aber auch der Schlüssel zu dynamischen Komponenten, die on-the-fly erzeugt werden, und somit auch zu den aus React bekannten Higher Order Components. Außerdem wird künftig die Internationalisierung auf Ivy basieren. Die Idee ist es, damit für Übersetzungstexte eine Art one-time-binding zu realisieren. Aber auch Lazy Loading auf Komponentenebene und das Erweitern von Angular durch Drittanbieter wird mittelfristig durch Ivy vereinfacht bzw. erst wirklich möglich.
Dazu kommt, dass Ivy die Grundlage für Angular Photon ist. Dabei handelt es sich um einen hoch-experimentellen Betriebsmodus, der Server Side Rendering und Lazy Loading auf die nächste Ebene hebt und somit Angular nicht nur für Customer-facing Applications sehr attraktiv machen wird.
Thomas Hilzendegen: Ich hoffe, dass Ivy gerade hinsichtlich Web Components (dazu entsprechend Angular Elements) die Tür komplett aufstößt, so dass hier minimalgroße, isolierte (und damit in jedem anderen Framework – gerade in Legacy Anwendungen von ‚damals‘ – verwendbare) Komponenten entstehen können. Dadurch kann man sehr solide alte, gewachsene System in kleinen Teilen in die ‚neue‘ Welt migrieren, ohne den mehrere Jahre andauernden Relaunch als Ganzes durchführen zu müssen.
Christian Liebel: Bei Ivy freue ich mich zunächst auf die Verbesserungen hinsichtlich Performance und Bundle-Größen, welche die allermeisten Entwickler völlig ohne Aufwand erhalten werden. Durch das Lokalitätsprinzip von Ivy wird zudem die Stellung der Komponente gegenüber dem Modul gestärkt: So ist künftig das Nachladen einzelner Komponenten möglich – zuvor war das nur routen- beziehungsweise modulbasiert möglich.
Fabian Gosebrink: Besonders gespannt bin ich auf die Performance-Verbesserungen im Bereich der Bundle-Größen und der Ausführung. Es wird sicher spannend, diesen Vorher/Nachher-Vergleich anzustellen. Wobei man ja heute Ivy schon benutzen kann. Welche Auswirkungen Ivy auf das Ökosystem haben wird, bleibt abzuwarten. Es bleibt aber mit Sicherheit spannend!
Vielen Dank für eure Antworten!
Die Fragen stellte Ann-Cathrin Klose
Ann-Cathrin Klose hat allgemeine Sprachwissenschaft an der Johannes Gutenberg-Universität Mainz studiert. Seit Februar 2015 verstärkt sie das Team von Software & Support Media, seit 2017 ist sie als Redakteurin im Team von entwickler.de und für das Entwickler Magazin tätig und beschäftigt sich im Schwerpunkt mit JavaScript-Themen.
